When Translated Code Won’t Run

It is not unusual for code produced by Mac F2C to compile without any problems, but crash and burn when run.  In fact, if you get to the ccommand() dialog (the one that asks you to set up standard input and standard output), but crash immediately there after, it is almost certain that you are blowing out the stack space.  The problem and its solution are described below.

The problem arises because FORTRAN allocates memory for all its variables statically.  The C code produced by Mac F2C by default uses automatic storage for most variables.  On the Macintosh automatic variables get stored on the stack.  When the FORTRAN code declares large arrays (quite common in FORTRAN code), these become large arrays on the stack in the C version.  Because less than 24K is normally allocated as stack space by default on the Macintosh, your program blows out the stack.

There are two “quick” fixes to this problem which usually work (either separately or in combination).  There is also a more tedious, but 100% reliable fix that involves modifying the code generated by Mac F2C.  All three of these fixes are described below.

Quick Fix 1:  Use Static Storage

The first quick fix to try is to translate the FORTRAN code with the Make local variables automatic vice static option in the C Output options dialog unchecked.  This will move all of the large arrays from the stack to the global data space.  You should also increase the memory partition for your program (either in the Finder’s Get Info dialog if it is a free-standing application, or in the appropriate THINK, Symantec, or CodeWarrior dialog if it is under development) to allow for the extra memory required by the large global arrays.

This “fix” will often solve the problem.  However, because some C/C++ compilers still impose a 32K limit on the amount of global data per file, you can still have problems with files that have too many large arrays in them.  If you are lucky, you can divide the file somehow so that the arrays are split among several files and now don’t violate the 32K/file limit.  However, that might not be possible if, for example, all the arrays appear within a single subroutine.  If not, try “Quick Fix 2” or the “True but Tedious Fix” described below.

Quick Fix 2:  Enlarge the Stack

Both F2CMain.c and F2CMain.cp contain code that adjusts the size of the stack when generating 68K code.  You can simply modify a single line in these files to adjust the stack size to whatever you need.  

If you are generating PPC code, then you can set the stack size to anything you need by modifying the PEF, but I don’t have a PowerMac, so I don’t know how you would do this.  Sorry.

To change the stack size when generating 68K code, open either F2CMain.c or F2CMain.cp, as appropriate, and search for the following segement of code:

#define kDesiredStackSize  (40*1024L) 
/* 68K stack size set to 40K bytes */
#if GENERATING68K && defined(kDesiredStackSize)

  if ( kDesiredStackSize > LMGetDefltStack() )

        Ptr newApplLimit = 
                           GetApplLimit() - (kDesiredStackSize - LMGetDefltStack());

    SetApplLimit( newApplLimit );

#endif
/* increase stack size */

The key line is the one that defines kDesiredStackSize.  It is currently set to 40KB.  If you want to make the stack 200KB, simply edit the line, changing the 40 to 200, so the line now reads:

#define kDesiredStackSize  (200*1024L) 
/* 68K stack size set to 200K bytes */

After making the change, simply rebuild your executable and give it a try.  It’s hard to determine the correct stack size.  You can scan your source code and add up the size of the big arrays to get a rough estimate.  In any case, some trial-and-error will be required.  If you increase the stack size significantly, remember also to increase the memory partition for your program by a corresponding amount.

The “increase the stack size” fix should generally work.  If it doesn’t, you can modify the code generated by Mac F2C to move the memory allocations from the stack to the heap (i.e., from automatic to dynamic allocation).  How to do this is described in the next section.

True but Tedious Fix:  Allocate Memory Dynamically

If all else fails, the only solution is to edit the C code so that it allocates the memory dynamically.

Let’s work an example.  Consider the following simple FORTRAN program:

    program example
    
    double precision d
    dimension a(100,100), b(100,200,20)
    dimension d(50,20,10)
    
    a(100,100) = 1.0
    b(100,200,20) = 1.0
    d(50,20,10) = 1.0d0
    
    stop
    end
 
Basically all it does is allocate three arrays.  Note that the arrays are not that large by FORTRAN standards.  Selecting the option that allocates local variables automatically, this program translates into:

/* JUNK.f -- translated by f2c (version 19941113).
   You must link the resulting object file with the libraries:
    -lf2c -lm   (in that order)
*/

#include "f2c.h"

/* Main program */ MAIN__(void)

    /* Builtin functions */
    /* Subroutine */ int s_stop(char *, ftnlen);

    /* Local variables */
    real a[10000]   /* was [100][100] */, b[400000] /* was [100][200][20] 
        */;
    doublereal d[10000] /* was [50][20][10] */;

    a[9999] = 1.f;
    b[399999] = 1.f;
    d[9999] = 1.;
    s_stop("", 0L);
    return 0;
 /* MAIN__ */

/* Main program alias */ int example_ ()  MAIN__ (); return 0; 

Note how in the C version 410,000 reals and 10,000 doublereals are allocated on the stack—that’s over 1.5MB on the stack.  Your program will crash the moment it enters the MAIN__() function.  If you tried using static vice automatic variables you would have over 32K of global data in one file and it wouldn’t build under THINK C.  

Multi-dimensional arrays can be quite large even when their individual dimensions are small.  It’s easy to blow out the stack or the THINK C limit on global data per file with even one or two arrays of three or more dimensions.  I’ve also seen programs get into problems because they have lots of small arrays.

The solution is to replace the array variables with pointers and allocate the memory for them using malloc() or any of its cousins.  Because C treats pointers and arrays similarly, the rest of the code works without any changes. 
 
Applying this technique to the example yields the following modified code:

/* JUNK.f -- translated by f2c (version 19941113).
   You must link the resulting object file with the libraries:
    -lf2c -lm   (in that order)
*/

#include "f2c.h"

#define NEW_CODE            /* <========  to make the changes clear */

#ifdef NEW_CODE
#include <stdlib.h>         /* Get prototypes for malloc(), etc */
#endif

/* Main program */ MAIN__(void)

    /* Builtin functions */
    /* Subroutine */ int s_stop(char *, ftnlen);

    /* Local variables */
#ifdef NEW_CODE 
    real        *a, *b;         /* Pointers instead of arrays */
    doublereal  *d;         
#else
    real a[10000]   /* was [100][100] */, b[400000] /* was [100][200][20] 
        */;
    doublereal d[10000] /* was [50][20][10] */;
#endif

#ifdef NEW_CODE                                 /* allocate the memory */
    a = (real *) malloc( 10000*sizeof(real) );
    b = (real *) malloc( 400000*sizeof(real) );
    d = (doublereal *) malloc( 10000*sizeof(doublereal) );
    /* Remember to check a, b, and d for NULL (e.g., out of memory) */
#endif

    a[9999] = 1.f;
    b[399999] = 1.f;
    d[9999] = 1.;
    
#ifdef NEW_CODE
    free( a );          /* Don't forget to free the memory */
    free( b );
    free( d );
#endif

    s_stop("", 0L);
    return 0;
 /* MAIN__ */

/* Main program alias */ int example_ ()  MAIN__ (); return 0; 

This version of the program will work fine so long as there is enough heap space to allocate the memory requested in the malloc() calls.  You can add more heap space by simply increasing the partition size of the program (either in the Finder’s Get Info dialog if it is a free-standing application, or in the appropriate THINK, Symantec, or CodeWarrior dialog if the code is under development).

This modified version will also work if the variables a, b, and d had been declared static vice automatic.